As data processing systems become more powerful, more complex, and more highly interconnected, interpreted languages of various kinds are growing in importance. In non-interpreted languages, source programs are converted into the machine language for some particular CPU, and then stored, transmitted and executed in machine-language form. Computer programs that perform this function are typically referred to as compilers.
However, when using a computer program known as an interpreter the source programs are stored, transmitted and executed in a higher-level language. The interpreter is required at execution time to read the source program and carry out the instructions that it contains.
Interpreted languages tend to execute slower than other types of languages. That is, an interpreted source program may execute more slowly than the same source program that has been previously compiled into the machine code of the host CPU. However, the use of interpreters provides several advantages, including an ability to execute the same program on many different CPUs and operating systems (as long as each CPU and operating system has an interpreter for the language).
Interpreters are often embedded inside application program subsystems. For example, one widely used word processing program contains an interpreter for a specific language in which the word processor macros are written. The LotusNotes.TM. product contains an interpreter for LotusScript.TM., one of the languages in which LotusNotes.TM. macros are written. Also, several Web browsers contain interpreters for Java.TM., a language in which programs of various kinds are written, and made available on the World Wide Web (WWW). In many cases, these application program subsystems include application programming interfaces (APIs) which allow other programs to interact with the application program subsystem. One common feature offered by many APIs is the ability for an external program to access, create and execute programs written in the application program subsystem's interpreted language.
There are various types of programs, including anti-virus programs and general security programs, which may need to examine interpreted programs designed for application program subsystems. For a variety of purposes, such an external program may need to determine at least a subset of the actions that a given interpreted-language program would take, if it were to be executed by the interpreter contained in some application subsystem. Since existing APIs do not provide powerful features to allow this determination, designers of these external programs are faced with the choice of either implementing at least a subset of the interpreters themselves, or not supporting detailed examination of programs written for these interpreters. The former course of action is difficult, as implementing an interpreter for a powerful macro language can be costly and time-consuming, and it is not easy to ensure that the implemented interpreter actually behaves as the real one would in all relevant cases. The latter course of action is dangerous, as it may lead to exposure to viruses or security attacks.